---
title: Triggers
---

# Concept

Triggers are the entry points to your Blok [Workflows](./workflows.mdx). They are specific events or conditions that, when they occur, initiate the execution of an associated workflow. Without a trigger, a workflow is just a definition; triggers bring them to life by starting the process.

## What is a Trigger?

Think of a trigger as the starting gun for a race (the race being your workflow). It listens for a particular signal and, upon receiving it, kicks off the defined sequence of [Nodes](./nodes.mdx).

Blok supports various types of triggers to cater to different use cases. Common trigger types include:

*   **HTTP/HTTPS**: Initiates a workflow based on an incoming HTTP request (e.g., a user accessing a URL, an API call from a frontend application or another service). This is one of the most common triggers for web-based applications and APIs.
*   **Scheduled (Cron)**: Executes a workflow at predefined times or intervals (e.g., run a report every night at 2 AM, perform a cleanup task every hour).
*   **Message Queue**: Starts a workflow when a new message arrives in a specific queue (e.g., RabbitMQ, Kafka, AWS SQS). This is useful for asynchronous processing and event-driven architectures.
*   **gRPC**: Initiates a workflow based on an incoming gRPC request. This is suitable for high-performance, contract-based inter-service communication.
*   **Database Events**: (Potentially) Triggers a workflow in response to changes in a database (e.g., a new record inserted into a table). Support for this depends on the Blok runtime and integrations.
*   **Custom Triggers**: The framework might allow for the development of custom triggers to integrate with proprietary systems or unique event sources.

## Configuring Triggers

Each trigger type requires specific configuration. This configuration is typically part of the workflow definition (e.g., in the workflow JSON file).

### Example: HTTP Trigger Configuration (in Workflow JSON)

```json
{
  "name": "getUserProfile",
  "trigger": {
		"http": {
			"method": "GET",
			"path": "/",
			"accept": "application/json"
		}
	},
  "nodes": [
    // ... nodes for this workflow ...
  ]
}
```
In this example:
*   `type: "Http"` declares it as an HTTP trigger.
*   `config.path: "/users/{userId}"` defines the endpoint. The `{userId}` part indicates a path parameter that will be available in the [Context Object](./context.mdx).
*   `config.method: "GET"` specifies that only GET requests to this path will trigger the workflow.

## Trigger Data in the Context Object

When a trigger fires and a workflow instance begins, the data associated with the trigger event is typically passed into the workflow via the [Context Object](./context.mdx). Nodes within the workflow can then access this data.

For an HTTP trigger, this might include:
*   Request headers (e.g., `ctx.request.headers`)
*   Query parameters (e.g., `ctx.request.query.searchTerm`)
*   Path parameters (e.g., `ctx.request.params.userId`)
*   Request body (e.g., `ctx.request.body.payload`)

For a message queue trigger, it would include the message payload and any associated metadata.

## Multiple Triggers

While a single workflow definition usually has one primary trigger, advanced scenarios or specific Blok runtime features might allow a workflow to be triggered by multiple different event types or configurations, though this is less common and can add complexity.

## Choosing the Right Trigger

The choice of trigger depends entirely on how you want your workflow to be initiated:

*   For synchronous, request/response interactions (like building APIs), **HTTP** or **gRPC** triggers are suitable.
*   For background tasks that run on a schedule, use a **Scheduled (Cron)** trigger.
*   For decoupling services and processing events asynchronously, **Message Queue** triggers are ideal.

Triggers are the essential starting points for all operations in Blok . By understanding and correctly configuring them, you can effectively control when and how your application logic is executed.

This concludes the core concepts in the Introduction. You can now explore [Practical Examples](../examples/index.mdx) or dive deeper into [Fundamentals](../fundamentals/overview.mdx).
